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BACKGROUND OF THE INVENTION 



The present invention relates to the collection, storage, and retrieval of 
data on computer systems. More particularly, the present invention relates to a 
computer system for retrieving, modifying, and storing a plurality of topically, 
20 textually, or audio-visually related data records of a plurality of formats on a 
plurality of databases in conformance with a hypertext-linked, predefined topical 
organization. 

When a patient is in a hospital, either as an inpatient or an outpatient, 
a variety of information concerning the patient may be collected and recorded. 
25 This may be in the form of observations, measurements, lab results, vital sign 
indicators, procedure reports and associated graphics. Over a long period of 
treatment, hundreds of pages of information may accumulate in the patient's 
record. 

While the patient is in the hospital, it is typical that many different care 
30 givers, administrators, or insurance company employees will desire to view a 



-1- 

2- 



part of the patient's cumulative record. The conventional paper chart is not 
always useful, as there is only one copy of it, and some laboratory tests may 
not be entered into the chart on a timely basis. To solve this problem, 
hospitals have used a variety of database systems such as hospital 
5 information systems (HIS) and clinical information systems (CIS) to store and 
present patient information on computer displays. However, there is still a 
substantial amount of data that does not get placed into these systems. A 
variety of factors may inhibit an automated process of comprehensive 
retrieval of a patient's data, such as incompatible communication protocols 

10 and formatting schemes between computer systems, non-digitized data 

records including pictures and standardized forms, and the lack of adequate 
computer interfacing support for low-cost medical instruments or devices. It is 
also typical that word processing documents, rather than being automatically 
collected by a database system, are simply printed in the form of a paper 

15 copy to be inserted into the conventional chart. 

While various standardization committees have been established, e.g., 
HL-7, DOCOM, and IEEE, to develop common addressing schemes for 
hospital data, to date none have defined a consistent format to use for storing 
and retrieving data. For the sake of simplicity or due to limited resources, 

20 many manufacturers that use one or more of these standards choose to use 
only a portion of them; consequently their systems remain only partially 
compatible. 

Furthermore, even many hospitals with database systems lack a 
centralized retrieval system because related hospital reports are often stored 

25 on separate databases. For example, a patient's radiology catheterization 
report and hemodynamic catheterization reports may be created and stored in 
separate databases, though as far as the physician who performed the 
catheterization procedure is concerned, these two reports are really just one 
procedure and should be associated with each other. For further example, a 

30 physician reviewing an admission report may find that it references laboratory 
tests or observations made contemporaneous with or previous to the patient 
arriving at the hospital. Should the physician decide to review these other 
records, she will have to perform additional searches to locate them. In some 
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cases, this often cumbersome and time-consuming process results in care 
givers refraining from making complete use of the available patient 
information. 

In many hospitals when a patient is discharged, a paper copy of these 
5 records is made and sent to the admitting physician for his own record 
keeping purposes. The collection, copying, and storage of all of these 
records is a very time-consuming and labor-intensive activity. Further, the 
generally high risk of human error may manifest itself in the failure to return 
records to the correct patient's file or incorrect storage of a patient's entire file, 

10 effectively forfeiting the misplaced information. The physician is 

simultaneously confronted with the responsibility of filing and storing the 
paper copy in his own office. 

Some hospitals have purchased laboratory or information systems 
capable of long term storage of various records. While this may assist the 

15 hospital in retrieving past records, it may not help the admitting physician in 
referring to them, for he may not have access to the data directly or may not 
have the specific software required to retrieve the data. So with such 
advanced systems the physician is still provided with a paper copy for his 
records. 

20 Furthermore, many existing laboratory and information systems record 

information in a variety of inconsistent formats. Some of these formats are 
proprietary to the manufacturer of the specific system. Each system may use 
a separate database scheme to gain access to the data. Substantial efforts 
to get these systems to communicate with each other have not yielded 

25 satisfactory results. For example, many large medical information systems 
use complicated data exchange protocols; but these protocols are unwieldy 
for simple, often portable instruments which lack the hardware and software 
capacity to conform to such protocols. 

Some reports may be created using a word processor. These may 

30 originate in a department of the hospital or in a physician's office. These 
reports, which may be kept in a conventional file cabinet, are not always 
included with the rest of the patient's reports. 
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What is needed is an effective alternative to creating paper records 
that must be copied and meticulously tracked, an alternative that would permit 
physicians to access the data economically and easily in their own offices. 
Such a system would permit a system user to enter a keyword to retrieve a 
5 specific data record of a patient, retrieve the requested record from whichever 
database it is stored to, reformat the data record with hypertext links to 
related patient records, and return the requested record to the system user for 
display on a browser. The system would preferably use a mark-up language 
such as the well-known Hypertext Markup Language (HTML) or JAVA so that 

10 it could utilize inexpensive, standard software packages. The system would 
also be operable to format data records stored on the various databases of 
the computer network systematically, periodically, or automatically upon the 
creation of new, or the modification of existing, data records. The system 
would be operable to collect all data records pertaining to a specific patient, 

1 5 doctor, or other subject, modify them to support display through a Java 
applet, internet browser, or other universal display standard, generate 
additional patient files to organize the data records in a hypertext directory 
structure, and store the data records and files on a mass-media storage 
device such as a CD-ROM. 

20 In addition, it would be advantageous to have a system which permits 

both the storage and the retrieval of data records according to a standardized 
addressing scheme which can be determined solely by the use of certain 
keywords known to the various users of the system. Such a system could 
employ standard word processing software to enable multiple users to create 

25 and reference the various data records. The system would recognize certain 
keywords entered by the user during creation of the data record and use 
those keywords to determine the appropriate location (e.g., database, 
directory and file name) to store the record according to a predetermined 
addressing scheme. Similarly, it is desirable for the users of the system to be 

30 able to locate particular data records using a few keywords without having to 
know the complexities of which database the record is on, the format of the 
record, the file name or the directory address. 
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BRIEF SUMMARY OF THE INVENTION 



It is an object of this invention to provide a means of processing and 
converting existing data records formatted, structured, and accessed 
according to a multitude of disparate standards to common standards by 
5 which they may be accessed, controlled, and/or displayed through a single 
interactive display program. It is another object of this invention to provide 
conventions for exploring data records for references to contextually related 
data records and modifying, generating, embedding, and appending links and 
data-retrieving codes in and to said related data records, whereby to organize 

10 said related data records in a hypertext tree structure. A further object of this 
invention is to store a group of related data records organized in a hypertext 
tree structure to a mass storage device, such as a hard disk or CD-ROM, 
through which the data records may be retrieved, displayed, and controlled 
through a single interactive display program. In order to minimize costs and 

15 maximize end-user accessibility, the standards and conventions used by the 
present invention for modifying data records and addressing schemes 
facilitate display through a widely-familiar and low-cost display program such 
as an Internet browser. 

The invention may be adapted for use in a wide variety of applications, 

20 and is suitable for any environment in which numerous data records having 
one or multiple forms and/or formats are to be collected, stored, archived, 
retrieved, or translated. By way of illustration and not by way of limitation, the 
invention is presented in the context of a hospital environment, in which 
typically there are numerous computer systems in use by various health care 

25 professionals in one or several hospitals, and each professional often desires 
to have access to the patient records created by other professionals in that or 
other hospitals. 

A typical setting for the present invention provides multiple databases 
and workstations linked via a network wherein the databases store data 
30 records in a variety of formats and the workstations utilize user interfaces to 
input, retrieve, and manipulate data records. The present invention utilizes 
specification tables identifying each of the information processors or 
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databases used by the hospital, the types of data records stored by the 
databases, and instructions and algorithms for accessing, modifying, and 
processing data records and their addresses, depending on the data type. 
Similar specification tables are also kept to identify each workstation where 
5 word processor, spreadsheet, or other records, including those downloaded 
from portable medical devices, may be held. 

When a system user at a workstation linked to the hospital computer 
network equipped with the present invention submits a request for a particular 
patient record, the invention parses the data request for an address root and 

10 other pertinent information about the data record to be retrieved, which may 
include the time and date the data record was created or last modified and a 
patient ID. Using this information incorporated in the data request and in the 
specification tables, the invention modifies the existing data request into a 
URL or other addressing convention, as necessary, to retrieve the data record 

15 from the appropriate database. 

After retrieving the data record, the invention may modify it to make it 
compatible with a standard supported by the common interactive display 
browser used by the system. For example, the invention may convert a text 
document to an HTML document or convert graphics, video, or audio records 

20 to browser or Java-enabled formats. Further, depending on the formatting 
specifications for a particular data type, the invention may identify key words, 
links, and programming codes embedded in the data record, modifying them 
and inserting additional hypertext links and programming codes as necessary. 
For example, it may be desirable that a hypertext link referencing the patient's 

25 demographics and insurance information be inserted into each record 
reporting on the patient's condition, status, or profile for quick and easy 
referral. As another example, it may be desirable to place a hypertext link in 
a radiology catheterization report that references the hemodynamic 
catheterization report and vice versa so that each refers to the other. 

30 In this manner a hospital may use Internet or Intranet compatible 

databases with databases that are not compatible, and may choose to use 
URL addresses of its own choice independent of what the individual vendors 
have chosen. The administrator may also preprogram the data translation 
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and collection system to link reports together as appropriate, so that care 
givers may more quickly and directly refer to relevant or related information. 
The translation process described here may be used on a dedicated system 
for this purpose or may be distributed among several processors including 
5 those of the database systems. 

Another aspect of the present invention includes means for receiving, 
processing, and storing hospital records systematically, periodically, or 
automatically as they are created or modified. In this mode of operation data 
records may be preformatted according to the hospital's specifications, 

10 allowing for quicker record retrieval during subsequent data requests. The 
translation operation may be allocated to a dedicated system for this purpose 
or may be distributed among several processors, including those of the 
database systems. 

A further aspect of the present invention includes means for 

1 5 periodically retrieving and filing the contents of a designated area of each 
workstation's disk. For example, word processing documents generated at a 
workstation may be stored in a designated area, such as a special "collection" 
drive or folder, to which the hospital computer network has access. The 
invention would retrieve the data records stored in the collection folder, and 

20 identify, interpret, and modify them before storing them in an appropriate 
database. 

Yet another aspect of the present invention includes means for 
retrieving, processing, and storing all of a patient's data records that are 
available on the hospital's computer network onto a mass media storage 

25 device, such as a CD-ROM. For example, this process may be initiated by 
submitting a collection request identifying the patient's ID number or other 
identifier uniquely identifying the patient. The invention submits requests, 
passwords, macros, and programming codes, as appropriate, to each of the 
databases and workstations that include portions of the patient's cumulative 

30 record. Each record retrieved is processed and modified as above — as if the 
particular record had been requested by a system user. The invention not 
only collects applicable data records, but also multimedia clips, applets, 
browser extensions, "plug-ins," and other application modules addressed by 
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programming codes embedded in the patient's data records. Substitute files 
explaining the absence of a linked record or module are created for data 
records or modules regarded as inappropriate for storage and distribution on 
an unsecured or uncontrolled medium. The invention would also create a 
5 "master file for the patient analogous to a "home page" for a website or the 
root directory of a tree structure, containing links to other patient-related files 
and data records. The master file may have hypertext links to patient records 
and to additional (secondary) control files, which in turn have hyperlinks to 
more patient data. After completing these collection routines, the invention 

10 would transfer the collection of data records, applets, browser extensions, 
and other data and programming modules to a mass-storage device. In this 
manner a patient's cumulative patient record could be stored on a single 
CD-ROM or other high-density storage device, cheaply distributed to other 
hospitals or health care professionals serving the patient, and be conveniently 

15 accessed by those hospitals and health care professionals. 

The present invention also provides a wordprocessor employing a 
standardized addressing scheme, wherein the wordprocessor recognizes 
keywords entered by a user who is either creating and storing a data record 
or attempting to locate a data record among numerous data records at 

20 different addresses on a plurality of computer databases. 

Thus, the present invention provides first a plurality of databases on 
which a variety of data records are stored. The databases are in 
communication with one or more processors which interpret input data from a 
user interface and direct the storage and retrieval of data records. The 

25 databases and processors may be linked via a network, or one or more of the 
databases may communicate locally with an associated processor, as in a 
personal computer. The invention also provides a plurality of user interfaces, 
such as combinations of keyboards, video displays, microphones with voice 
recognition, and other input devices (e.g. rf receiver, etc.), through which 

30 system users create, store, retrieve and display data records. These user 

interfaces can be simple terminals which communicate with a processor and a 
database over the network, or they can be part of an integrated 
interface/processor combination, such as in a personal computer. 
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For accepting keywords from the user and determining the storage 
location of a data record to be stored or retrieved, the invention includes a 
wordprocessor having certain defined functions. For the creation of data 
records, the wordprocessor accepts various information from the user to 
5 identify the user and the type of record being created, as well as other 
information which may uniquely identify the record and its storage location 
after the record is completed and saved, or "published." The wordprocessor 
uses these keywords, or specialized information fields, to determine the 
location at which the record is to be stored and employs a standardized 
10 addressing scheme compatible with or comparable to the Universal Resource 
Locator (URL) addressing used on the global computer network (Internet). 
The wordprocessor automatically creates a link between the keyword in the 
data record and the address of the data record on the computer system. 



15 entered by the user to a predetermined list of keywords known to be used in 
the system and may prompt the user for a different keyword when no match is 
found. Once the user enters a sufficient number of recognized keywords to 
uniquely identify the data record being created or sought, the wordprocessor 
determines the unique address of the data record according to a 

20 predetermined, standardized addressing scheme so that the record may be 
stored or retrieved. 

When a data record is created and stored, the wordprocessor creates 
a link, in the manner of a hypertext link, between a keyword uniquely 
identifying the particular record and its unique address (URL) on the computer 

25 system. To this end, the wordprocessor identifies background information 
within the record and uses the background information and, in some cases, 
the keyword itself, to form the address link pointing to the record. This link 
points to the unique address of the record and will enable other users to 
retrieve the record when the same keyword is used in a request for a data 

30 record. In the same manner, other data records containing this same 
keyword will contain a link to that record, permitting users to create data 
records which refer to other data records by use of a hypertext link. 



The wordprocessor also includes a function which compares text 
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The word processor included in the invention contains a monitoring 
function which monitors free text entered by the user to determine whether 
the user is creating a hypertext reference at a place in the data record other 
than in a specified keyword field. This monitoring function continuously 
5 surveys text/data being input by the user so that hypertext links in a data 
record or report can be created by the user at will. 

The wordprocessor also includes an editing function which permits 
keywords, or hypertext references, in data records to be edited and 
determines whether a user is changing the keyword to another keyword or a 

10 non-keyword. This editing function attempts to match changed keywords with 
other known keywords to determine whether the user is referencing a 
different data record. The wordprocessor treats keywords or keyword 
phrases as singularities which cannot be edited without either deleting the link 
(URL or hyperlink) associated with the keyword or changing the hypertext link 

15 to a different hypertext link. 

The addressing scheme and hypertext links of the invention are 
suitable to be created by and used with conventional tools in common use for 
publishing documents on the Internet. Data records containing keywords and 
hypertext links may be created in a markup language such as Hypertext 

20 Markup Language (HTML), and the addressing scheme may comport with 
Internet URL addressing. Thus, the invention provides internet/intranet 
capabilities and may be operated with relatively inexpensive, commercially 
available HTML formatting software and Internet browser software. Other 
hypertext link preparation methods and other addressing schemes are 

25 possible. 

The invention further includes a system for linking first record 
references to a first record wherein the references are in a second record, the 
system comprising a database (DB) including at least one address format 
specifying an address format of the first record address and a processor 
30 linked to the DB and running a pulse sequencing program to perform the 
steps of receiving the second record, analyzing the second record to identify 
references to the first record and when a first record reference is identified, 
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using information from the second record to form the address of the first 
record as specified by the address format. 

Preferably the address format also specifies required information for 
forming the address for the first record, the DB further includes at least one 
5 record rule set (RRS) corresponding to the address format, the RRS 
specifying rules for gleaning the required information from a record and, 
wherein, when the first record is referenced in the second record, the 
processor gleans the required information from the second record in the 
manner specified by the RRS. 

10 Also, preferably, the DB also includes a data reference (DR) which is 

associated with the address format and wherein, when searching for a 
reference to the first record, the processor searches for instances of the DR. 
In one aspect the program includes a word processor, the DR is a text name 
associated with the first record and the first record address is a markup 

15 language data reference. 

In one embodiment the system is also for creating markup language 
data references between the first record references and the first record, the 
processor also, when a first record reference is identified, provides the first 
record reference to a user as a selectable segment and links the selectable 

20 segment to the first record via the first record address such that, when the 
selectable segment is selected, the first record is provided to the user. 

Where a selectable segment is provided, the processor may further, 
after the selectable segment is provided, perform the steps of, when the 
second record is accessed, monitor changes to the second record and, when 

25 the selectable segment is modified, de-linking the selectable segment and the 
first record. 

In another aspect the DB includes a plurality of address formats and 
their associated RRSs and DRs. In this case, the processor searches the 
second record for any of the DRs and, when any of the DRs is identified, the 
30 processor identifies the associated address format and RRS, gleans the 
required information from the second record in the manner specified by the 
associated RRS and forms the address corresponding to the first record. 
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In yet another aspect the system includes an interface for entering the 
second record, the second record entered in record segments and, wherein, 
the processor runs the program as second record segments are entered via 
the interface. 

5 In another aspect the system is for use with a data specifying device 

wherein the step of receiving includes receiving the second record from the 
data specifying device. 

Furthermore, the invention includes a system which receives database 
records, each record including a separate information set and characterized 

10 by at least one data type, for a specific record, the system using the specific 
record's information set to construct a record address which enables easy 
subsequent record access, the system comprising a database (DB) including 
at least one address format which is associated with the at least one record 
type and which specifies a unique set of required information to form a record 

15 address for the record type. The system also including a processor linked to 
the DB and running a pulse sequencing program to perform the steps of, for 
the specific record receiving the information set, confirming the data type and 
the associated address format, analyzing the information set to glean the 
required information, using the required information to form a record address 

20 as specified by the address format and storing the record at the record 
address. 

In one embodiment there are a plurality of data types, the DB includes 
a separate address format for each of the different data types and the step of 
confirming includes the steps of determining the data type and the associated 
25 address format. 

In one embodiment the DB further includes at least a separate record 
rule set (RRS) corresponding to each of the address formats, each RRS 
specifying a unique set of rules for gleaning required information from a 
record and, wherein, the processor gleans required information in the manner 
30 specified by the RRS. 

Preferably the program is a first application program and the processor 
also performs a second application program to link stored records which are 
referenced in a first record to the referenced records, to this end the 
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processor further performing the steps of, after at least one record is stored, 
searching the first record for a reference to a stored record, when a reference 
to a stored record is identified, determining the address associated with the 
referenced record, providing the reference to a user as a selectable segment 
5 and linking the selectable segment to the referenced stored record via the 
record address such that, when the selectable segment is selected, the 
record is provided to the user. 

Preferably, the processor provides a data reference (DR) for the record 
information set, the DR useable to refer to the record in other records, the 
10 processor, when searching for a reference in the first record, searching for the 
DR. 

Also, preferably, after the record address is formed, the processor also 
correlates the DR with the record address and stores the DR along with the 
record address, the processor determining the address associated with a 

15 reference by identifying the address associated with an identified DR. 

In one embodiment the RRS is a first RRS and the DB also associates 
a second RRS with the address format, the second RRS specifying rules for 
gleaning the required information from the first record, when a DR is gleaned 
from an information set, the processor also correlating the DR with the 

20 address format and storing the DR along with the address format, the 

processor determining the address associated with a reference by, when a 
DR is identified, identifying the address format associated with the DR, 
identifying the second RRS associated with the identified address format and 
the required information specified by the identified address format, gleaning 

25 the required information from the first record as specified by the second RRS 
and forming the record address using the required information and as 
specified by the address format. 

The invention further includes a system which receives database 
records, each record including a separate information set and characterized 

30 by at least one data type, for a specific record, the system using the specific 
record's information set to identify a record address which enables easy 
subsequent record access. The system is also for use with a data specifying 
device which provides the database records, including at least one field 
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specifying a data reference. The system comprises a receiver for receiving 
records from the specifying device and a processor linked to the receiver and 
running a pulse sequencing program to perform the steps of, for a specific 
record, receiving the information set, identifying the DR, using the DR to 
5 identify a record address for the record and storing the record at the record 
address. 

The specifying device may be a hand held device or a database or 
some other suitable specifying device (e.g. a dictaphone). In addition, the 
specifying device, in addition to specifying the DR, may also specify other 

10 information which is used to identify the address. 

According to yet another embodiment of the invention, a record being 
searched may be characterized by a data type and the data type may be 
associated with a specific RRS for gleaning information therefrom and, when 
a DR is identified in a record, the system may determine the data type of the 

15 searched record to identify the RRS to be used to glean the required 
information. 

Moreover, the invention further includes methods to be used in 
conjunction with the systems described above. 

These and other objects, advantages and aspects of the invention will 
20 become apparent from the following description. In the description, reference 
is made to the accompanying drawings which form a part hereof, and in which 
there is shown a preferred embodiment of the invention. Such embodiment 
does not necessarily represent the full scope of the invention and reference is 
made therefor, to the claims herein for interpreting the scope of the invention. 



25 BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 



Fig. 1 is a block diagram of a medical computer network according to 
the present invention, including a plurality of databases for data record 
storage and a data translation and collection system; 

Fig. 2 is a graphical illustration of a physician office workstation; 
30 Figs. 3A and 3B are tables showing the contents of the "Database 

Table" and Tile Format Instruction Table" maintained and used by the data 
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translation and collection system to access, translate, reformat, and store 
data records kept on databases on the medical computer network; 

Figs. 4A and 4B are tables showing the contents of "List of 
Workstations" and "Report List" maintained and used by the data translation 
5 and collection system to access, translate, reformat, and store data records 
kept on workstations on the medical computer network; 

Figs. 5A-5F are functional flow charts showing the steps used to collect 
and process a related set of data records from various databases, create a 
structured set of control files containing hypertext links to the collected data 
10 records, and store the data records and control files to a storage device; 

Fig. 6A is a graphical representation of a master file in HTML format 
through which all of a single patient's medical records created at a hospital 
equipped with the present invention may be viewed; 



15 viewed by a system user with a network browser; 

Fig. 7A is a graphical representation of a secondary control file in 
HTML format providing a hypertext-link embedded discharge report; 

Fig. 7B is a graphical representation of the secondary control file of 
Fig. 7A as viewed by a system user with a network browser; 
20 Fig. 8A is a graphical representation of another secondary control file 

in HTML format providing a structured list of hypertext links to a plurality of 
cardiology reports; 

Fig. 8B is a graphical representation of the secondary control file of 
Fig. 8A as viewed by a system user with a network browser; 
25 Fig. 9A is a graphical representation of a tertiary control file in HTML 

format providing a list of electrocardiogram reports; 

Fig. 9B is a graphical representation of the tertiary control file of Fig. 
9A as viewed by a system user with a network browser; 



30 Catalogue" maintained and used by the data translation and collection system 
to discriminate the data type and database location of a requested data 
record from the alphanumeric string requesting the data; 



Fig. 6B is a graphical representation of the master file of Fig. 6A as 



Fig. 10 is a table showing the contents of the "Data Request 
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Fig. 1 1 is a graphical representation of a data request containing an 
address root and descriptor; 

Figs. 12A-12C are a functional flow chart showing the steps used to 
receive a request for a data record, translate the request, retrieve the data 
5 record, and reformat the data record prior to sending it to its requested 
destination; 

Figs. 13A-13C are a functional flow chart showing the steps by which 
the data translation and collection system processes a data record received 
or retrieved from a workstation or database system on the medical computer 
10 network, reformat the data record, assign it a URL address, and deliver it to a 
database for storage; 

Figs. 14A-14B are textual representations of a URL address as 
received and reformatted by the data translation and collection system; 

Fig. 14C is a graphical representation of a report referenced by the 
1 5 URL address of Fig. 14B as it would be viewed by a system user through a 
network browser; 

Fig. 14D is a textual representation of the report of Fig. 14C as 
modified to include data references in the form of HTML codes; 

Fig. 14E is a graphical representation of the modified report in Fig. 14D 
20 as it would be viewed by a system user through a network browser; 

Figs. 15A-15B are a functional flow chart showing the steps by which a 
data record is parsed to locate data references within it; 

Fig. 16 is a flow chart illustrating a method of forming or building record 
addresses using a record rule set and an address format in real time 
25 according to the present invention; 

Fig. 17 is a is a graphical representation of a sample patient report during 
its creation by a user of the computer system according to the invention; 

Fig. 18 is a graphical representation of text of the report of Fig. 17 after 
being converted to HTML format and having hypertext links to URL addresses 
30 substituted for their associated data references; 

Fig. 19 is a graphical representation of the report of Fig. 17 with hypertext 
links, as viewed by a system user with a network browser or other request 
handler routine; 
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Fig. 20 is a schematic of specifying devices and a processor of the present 
invention; 

Fig. 21 is a table used by the wordprocessor of the present invention to 
build data base addresses for linking first record references in a second 
5 record to the first record; 

Fig. 22 is a table used in conjunction with the table of Fig. 21 for gleaning 
information from a second record which is required to form a data base 
address for a first record which is referenced in a second record; and 
Fig. 23 is a table similar to the tables of Figs. 21 and 22 which is used in 
10 another embodiment of the present invention to build data base addresses for 
linking first record references in a second record to the first record. 

DETAILED DESCRIPTION OF THE INVENTION 

Referring now to Fig. 1, the invention is illustrated as a medical 
computer network 100, including a plurality of hospital based workstations 

15 102 (which may be personal computers), a plurality of physician office 
workstations 104 which may also be personal computers, a plurality of 
databases 106 which may be provided by a multitude of vendors with 
separate data structures and data elements. The computer network 100 may 
also comprise an Admit, Discharge, and Transfer (ADT) system 108, a data 

20 translation and collection system 110, and a Hospital Information System 
(HIS) 111. The data translation and collection system 1 10 is not necessarily 
a separate physical element of the medical computer network 100, but is 
represented that way in the preferred embodiment for purposes of illustration 
only. It may be alternately recognized as a program application or even an 

25 aspect of a network operating system, the operations of which may be 

distributed over and performed by many different processors, workstations, 
and databases on the medical computer network 100. 

Databases 106, computer systems 108, 110, 111, workstations 102, 
and physician office workstations 104 may communicate with each other via a 

30 communication network 112, which may be a combination of local and wide 
area networks, using Ethernet, serial line, wireless, or other communication 
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standards. Communication network 112 may also be arranged in such a 
manner to be part of the Internet or as an individual Intranet. Each 
workstation 102, 104 includes a "collection" folder 105, a user interface 103 
which may include a network browser or similar display, entry, and retrieval 
5 program, a separate database 2 and a special wordprocessor 14. User 
interface 103 may be any means for permitting users to create data records 
and/or retrieve data records from the medical computer network 100 capable 
of supporting a network browser, such as well known keyboard and video 
terminal combinations or voice recognition hardware and software. 

10 Wordprocessor 14 runs under the direction of user interface/processor 

103 and governs the creation of data records, the recognition of keywords in 
the data records, the composition of hypertext links between the keywords 
and the data records, and the retrieval of data records in response to 
keywords input to the wordprocessor by the user or contained within a data 

15 record. 

Fig. 2 shows a typical physician office workstation 104 comprising a 
personal computer 107 which may include a display 118, and a CD-ROM 
drive 1 17 or other means of mass storage which may be removable. 

The data translation and collection system 110 maintains a file referred 

20 to as Database Table 130, whose contents are partially seen in Fig. 3A. For 
each database 106 included on the medical computer network 100, an entry 
is made in the Database Register 131 of the Database Table 130. 
Corresponding to each entry in the Database Register 131 is an address or 
addresses field 132 used to access the database on communication network 

25 112 and a separate File Format Instruction Table 134. 

A partial list of the contents of File Format Instruction Table 134 is 
seen in Fig. 3B, which includes records of each data type 136 stored by the 
database 106. Corresponding to each data type 136 in File Format 
Instruction Table 134 is a set of special instructions or program codes 142 

30 used to translate a request for such data to a format appropriate to the data 
type and database from which the requested information may be retrieved. 
Also corresponding to each data type 136 is a hypertext cipher or record rule 
set (RRS) 138 providing special instructions or codes used to add data 
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references (such as hypertext links) and to format the data, which instructions 
or codes may include decompression algorithms. In addition, the RRS 138 
also specifies rules for gleaning information from a record which can be used 
to form a record address. Hereinafter the terms hypertext cipher and RRS 
5 may be used interchangeably to mean the same thing. 

Further corresponding to each data type 136 is a URL cipher or 
address format 140 used to generate an address to store the designated type 
of data. The address format 140 specifies information which is required to 
form an address for an associated record type and also specifies the order of 

10 the information in the resulting address. Hereinafter the terms address format 
and URL cipher may be used interchangeably to mean the same thing. 

The data translation and collection system 110 may also retain a file 
referred to as Data Request Catalogue or database table (DBT) 500, whose 
contents are partially seen in Fig. 10. The Data Request Catalogue or DBT 

1 5 500 includes an array of Data Request Address Roots or data references 
(DRs) 504, to each element of which corresponds fields identifying the data 
type 136, the database 106 in which the data type is located, and hypertext 
cipher 138 (which is kept also in the File Format Instruction Tables 134 (Fig. 
3B) of the Database Table 130 (Fig. 3A)). This file may be accessed when a 

20 request for data is received by the data translation and collection system 110 
to recognize the matching data request address root 504 which identifies the 
data type 136 and the database 106 on which it is kept. 



Figs. 12A-12C describe the operation of the data translation and 
25 collection system 110 (Fig. 1 ) in responding to requests to retrieve data, 

translating those requests to conform to the format required by the applicable 
database, retrieving the data, reformatting the data, and delivering the data to 
the appropriate destination. 

Commencing with Fig. 12A, in step 540 the data translation and 
30 collection system 110 receives a data record reference 520 (Fig. 11) in the 
form of a data request containing an address root 522 and descriptors 524 
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about the requested record. In some instances, a data request will originate 
from a system user accessing a hypertext link on a document displayed by 
the system's interactive display browser. In other instances, the data request 
will originate from a database or workstation application program. There may 
be several non-uniform but mutually distinguishable data request formats 
among the several hospital databases 106 (Fig. 1) on the medical computer 
network 100 (Fig. 1). Alternately, data requests may be uniformly and 
compatibly formatted for all records stored by various hospital databases 106 
(Fig. 1 ). For example, the data requests may be in the form of a URL with 
optional data fields sent with it to assist in identifying the record to be 
retrieved. 

In step 544, the address root 522 (Fig. 1 1 ) of the data record reference 
520 may be determined by removing the descriptors 524 — any patient 
identification, chronological details, or other non-addressing 
information — from the received data request. The descriptors 524 are 
temporarily stored for use in step 560. 

In step 548, a search is performed to locate a match for the address 
root 522 (Fig. 1 1 ) of the data record reference 520 among the data request 
address roots 504 (Fig. 10) listed in the data request catalogue 500 (Fig. 10). 
By finding a matching data request root address 504, the invention 
immediately identifies the data type 136 (Fig. 10), the database 106 used to 
store this data, and the hypertext cipher 138 providing special instructions 
used to format and add data references to the data. 

In step 552 the database 106 identified in step 548 is in turn 
referenced in Database Table 130 (Fig. 3A) to its corresponding File Format 
Instruction Table 134 (Fig. 3A) to determine the address(es) 132 (Fig. 3A) of 
the database 106 storing the data. 

In step 556 the data type 136 identified in step 548 is cross-referenced 
with the File Format Instruction Table 134 (Fig. 3A) identified in step 552 to 
locate the special instructions to request data 142 (Fig. 3B) used to translate 
the request to a format appropriate to the data type and database from which 
the requested information may be retrieved. These instructions may, for 
example, include passwords or macros needed to retrieve the data. 
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In step 560 a code is constructed using the database address(es) 
132 identified in step 552, the special instructions to request data 142 
identified in step 556, and the descriptors 524 — the patient identification, 
chronological details, or other non-addressing information — stored in step 
5 540. The code is submitted to the appropriate database to produce the 
requested data record. 

After the database has produced the requested data record, the record 
may in step 564 be received by the data translation and collection system 110 
for additional processing. 

10 The steps by which the data translation and collection system 

110 processes the selected data record are shown in Figs. 12B and 12C. In 
step 566, the system uses the hypertext cipher 138 to determine whether or 
not the data is stored in a proprietary format. If it is, the applicable proprietary 
software is used to decompress or translate the data. This may be done on 

15 the manufacturer's database 106, another computer processing system, or by 
the data translation and collection system 110 itself. 

In step 570, the record is parsed, discussed infra, to locate date 
references: hypertext links, multi-media requests, and key words or phrases. 
If none are found, the process advances to step 598, discussed infra. 

20 If there are data references, they may in steps 580 through 596 be 

reformatted so that the URL addresses are compatible with addressing 
protocols used by the hospital. In step 580, the address root 522 (Fig. 1 1 ) of 
the hypertext link or other data record reference 520 may be determined by 
removing the descriptors 524 — any patient identification, chronological 

25 details, or other non-addressing information — from the received data request. 
The descriptors 524 are temporarily stored for use in step 596. In step 584, a 
match for address root 522 is sought among the data request address roots 
504 (Fig. 10) listed in Data Request Catalogue 500, which locates the 
Database 106 and Data Type 136 corresponding to the matching Data 

30 Request Address Root 504. In step 592, the identified Database 106 and 
Data Type 136 are referenced in Database Table 130 (Fig. 3A) and the 
corresponding File Format Instruction Table 134 (Fig. 3B) to acquire the 
appropriate URL cipher 140 (Fig. 3B). In step 596, the URL cipher 140 
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processes the descriptors 524 — the patient identification, chronological detail, 
and other information — extracted in step 580 to modify or replace the 
hypertext link or other data reference found in the selected record. Steps 
580 through 596 may be performed for each hypertext link and reference to 
5 other data records found in the selected record. 

For some types of data records, the URL cipher 140 will generate 
addresses compatible with database formatting standards such as SQL or 
Oracle. 

In step 598 the data translation and collection system 110, using the 
10 Hypertext Cipher 138, converts any text portion of the selected data record 
into a browser compatible format, such as HTML format, and any graphics, 
audio, video, or other non-text information into a browser, plug-in, or Java 
compatible format. 

In step 600, the data translation and collection system 110 inserts 
1 5 hypertext links or other references to the selected record in accordance with 
the hypertext cipher 138 identified in step 548. If directed by the hypertext 
cipher 138, the record may also be interpreted and modified or reformatted. 

In step 604, the data translation and collection system 110, having 
retrieved and translated the requested record, forwards the record to the 
20 destination selected by the requesting workstation or processor. 

B. Receiving Patient Records for 
Translation and Address Formatting 

Figs. 13A-13C set forth an alternate embodiment of the operation of 
the data translation and collection system 110 (Fig. 1) with particular 

25 reference to receiving, translating, and formatting data records to facilitate 
access through browsers and hypertext links for future users. This 
embodiment is similar to that set forth in Figs. 12A-12C but may proceed 
independently of and prior to a request for such data. Thus in this 
embodiment the data translation and collection system 110 may serve to 

30 organize and format a patient's records prior to their being requested by a 
member of the medical staff. 
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Commencing with Fig. 13A, in step 640 the data translation and 
collection system 110 receives a data record from a database 106 which may 
include or be appended to other information specifying patient identification, 
chronological detail, the data type, and other information regarding the record. 
5 In step 644, the data translation and collection system searches each File 
Format Instruction Table 134 (Fig. 3A) corresponding to each entry in 
Database Register 131 of Database Table 130 to locate the data type 136 of 
the received data record. In step 648, the hypertext cipher 138 (Fig. 3B) of 
File Format Instruction Table 134 may be used to parse the record to identify 
10 additional information, such as patient information and the date and time of 
the record. 

In step 650, the system uses the hypertext cipher 138 (Fig. 3B) to 
determine whether or not the data is stored in a proprietary format. If it is, the 
applicable proprietary software is used to decompress or translate the data. 

15 This may be done on the manufacturer's database 106, another computer 
processing system, or by the data translation and collection system 110 itself. 

In step 654, the record is parsed, discussed infra, to locate data 
references: hypertext links, multi-media requests, and key words or phrases. 
If none are found, the process advances to step 682, discussed infra. 

20 If hypertext links or references to other data records are found, they 

may in steps 664 through 680 be reformatted so that the URL addresses are 
compatible with addressing protocols used by the hospital. In step 664, the 
root address 522 of the data record reference 520 — which may be in the form 
of a hypertext link — is extracted as in step 544 (Fig. 12A). Similarly, any 

25 descriptors 524 — such as patient identification, chronological detail, or other 
non-addressing information — contained in the data record reference 520 is 
also extracted and temporarily stored. In step 668, a match for this address 
root is sought among the Data Request Address Roots 504 (Fig. 10) listed in 
Data Request Catalogue 500 (Fig. 10), which locates the Database 106 (Fig. 

30 10) and Data Type 136 (Fig. 10) corresponding to the matching Data Request 
Address Root 504. In step 672, the data type 136 and Database 106 
identified in step 668 are cross-referenced with their corresponding File 
Format Instruction Table 134 (Fig. 3A) to locate the special instructions to 
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request data 142 (Fig. 3B). In step 676, the identified Database 106 and 
Data Type 136 are referenced in Database Table 130 (Fig. 3A) and the 
corresponding File Format Instruction Table 134 (Fig. 3B) to acquire the 
appropriate URL cipher 140 (Fig. 3B). In step 680, the URL cipher 140 
5 processes the descriptors 524 — the patient identification, chronological detail, 
and other information — extracted in step 664 to modify or replace the 
hypertext link or other data reference found in the received data record. 
Steps 664 through 680 may be performed for each hypertext link and 
reference to other data records found in the received data record. 
10 In step 682 the data translation and collection system 110, using the 

Hypertext Cipher 138, converts any text portion of the selected data record 
into a browser compatible format, such as HTML format, and any graphics, 
audio, video, or other non-text information into a browser, plug-in, or Java 
compatible format. 

15 In step 684, the data translation and collection system 110 inserts 

hypertext links or other references to the received data record in accordance 
with the hypertext cipher 138 (Fig. 3B) identified in step 548. If directed by 
the hypertext cipher 138, the record may also be interpreted and modified or 
reformatted. In step 686, the URL cipher 140 corresponding to the data type 

20 136 (Fig. 3B) of the received data record processes the descriptors 524 — the 
patient identification, chronological detail, and other information stored or 
extracted in steps 640 or 648 — to format a URL by which the received data 
record may be accessed. 



25 translated and formatted the received data record, forwards the record and its 
formatted URL to an appropriate database 106 for storage. 



Figs. 14A-14D set forth an example of the hypertext and URL 
30 processing performed by the data translation and collection system 110 (Fig. 
1 ) in response to a request for a data record. Fig. 14A proffers, by way of 
example, a URL address 700 that may be consistent with a standard hospital 
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format, that is received by the data translation and collection system 110. 
Embedded in this URL address 700 is information regarding the type of data 
704, the patient's identification 708, the date 712 and time 716 of the data 
requested, and a report designator 718. The type of data 704, combined with 
5 additional information, is an example of an address root 701 and the 

information referred to as 708, 712, 716 and 720 are examples of descriptors 
702. The data translation and collection system 1 10, by following steps 544 
through 560 as set forth in Fig. 12A, reformats the data request into a new 
data request 720 (Fig. 14B), which is compatible with the database system 

10 106 (Fig. 1) holding this data. 

Fig. 14C sets forth an example of a report 724 that may be produced 
by a database 106 in response to the data request 720 of Fig. 14B. Initially, 
the report is only a conventional text document. The data translation and 
collection system 110 (Fig. 1 ) may then convert the report into an 

15 HTML-compatible format 732 (Fig. 14D), inserting data request 736 and 
hypertext links 740 and 744 according to the hypertext cipher 138 (Fig. 3B). 
The hypertext links 744 may be inserted based upon the recognition of 
phrases or special character sequences, such as "Catheterization Reports" 
728, in the report, which may vary from report to report of the same data type 

20 depending on the each report's contents. 

Fig. 14E shows the text report 724 with imported image 737 as 
displayed on computer display 118 using a network browser software 
package after the report has been translated and modified. A system user 
seeking additional information regarding the patient's demographics could 

25 select hypertext link 740. A system user seeking either the radiology or 

hemodynamic report for this procedure could select the appropriate hypertext 



FIGS 5A-5E set forth a second alternate embodiment of the operation 
30 of the data translation and collection system 110 (Fig. 1) with particular 

reference to the steps used by the data translation and collection system 110 



link 744. 
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to retrieve and format data to produce a complete, organized, 
hypertext-linked, and browser-compatible collection of records pertaining to a 
person, place, thing, or event. This operation may be initiated by a system 
user executing the appropriate command or may be executed routinely and 
5 automatically by the hospital's Admit, Discharge, and Transfer (ADT) system 
or Hospital Information System (HIS) during a patient's stay or when a patient 
is discharged. 

In step 200, the data translation and collection system 110 (Fig. 1) 
receives a patient identification number, which may originate from a staffed 

10 workstation 102 (Fig. 1) or automatically from the ADT system 108 (Fig. 1) or 
HIS 1 1 1 (Fig. 1 ). This may be done, for example, when a patient is admitted 
or after one has been discharged. In step 204, the data translation and 
collection system 110 may request the dates for which the system user 
desires to collect data for the patient or the most recent admission dates from 

1 5 the ADT system 1 08 or HIS 111. In step 208, a file containing a list of 
received records will be opened, if previously created, or generated, if not 
previously created. Similarly, in step 212, a file containing a list of records to 
be retrieved is opened, if previously created, or generated, if not previously 
created. In step 216, the data translation and collection system 110 

20 references database table 130 (Fig. 3A) to locate and retrieve the first 

database entry in the database register 131 (Fig. 3A), the corresponding File 
Format Instruction table 134 (Figs. 3A and 3B) and the first data type 136 
(Fig. 3B) in the File Format Instruction table 134. 



25 106 (Fig. 1) on the medical computer network 100 (Fig. 1) to collect, translate, 
and format all records relevant to a patient's medical history. 

In step 220, the field containing special instructions to request data 142 
(Fig. 3B) corresponding to the data type 136 (Fig. 3B) being referenced by the 
data translation and collection system 1 10 is used to construct and format a 

30 message which is sent, using address 132 (Fig. 3A), to the database 106 
being referenced in database register 131 (Fig. 3A). This message may 
incorporate passwords, macros, or other codes, as necessary, to retrieve the 
data. In step 224 a data record is retrieved. 



Steps 220 through 276 set forth an iterative search of all the databases 
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In step 226, the record is parsed per the Hypertext Cipher 138 (Fig. 
3B) in the File Format Instruction Table 134 (Fig. 3B) to derive the date and 
time of the record. In step 228 the file name is added to the list of received 
records opened in step 208. In step 232, the list of records to retrieve opened 
5 in step 212 is checked for a reference to the retrieved record. If a reference 
exists, in step 236 it is removed from the list of records to retrieve. 

In step 240, the system uses the Hypertext Cipher 138 (Fig. 3B) to 
determine whether or not the data is stored in a proprietary format. If it is, the 
applicable proprietary software is used to decompress or translate the data. 

10 This may be done on the manufacturer's database 106, another computer 
processing system, or by the data translation and collection system 110 itself. 

In step 246, the record is parsed, discussed infra, to locate data 
references: hypertext links, multi-media requests, and key words or phrases. 
If none are found, the process advances to step 266, discussed infra. If there 

1 5 are data references, a check is made to determine if the data being 
referenced had been located previously (step 254). If it had not been 
previously located, the record is added to the List of Records to Retrieve (step 
258). In ste 262, all hypertext links and other data requests are reformatted 
through use of the URL Ciphers 140, maintained by the data translation and 

20 collection system 1 10 for each Data Type 136. This is done in a manner 
similar to steps 580 to 596, discussed supra. Thus when the retrieved data 
record is later displayed, secondary files referenced by it will be included for 
display and the system user will not be presented an incomplete record. 



25 Cipher 138 is used to convert text to HTML format, graphics, audio, video, or 
other non-text information into a browser, plug-in, or Java compatible format. 

While not shown in the flow chart of Figs. 5A-5E, if the data translation 
and collection system 110 retrieves a record that includes a program code 
module such as a Java applet, the data translation and collection system will 

30 attempt to retrieve a copy of the applet from an address specified by the 
applet program code, generate a new address for the applet copy which will 
be stored with the patient's data record collection, and modify the program 
code module to reflect the new address. Similarly, if the data translation and 



In step 266, whether there were data references or not, Hypertext 
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collection system 110 retrieves a record that requires a browser extension or 
"plug-in" in order to be properly viewed, a copy of the applicable extension or 
"plug-in" is also retrieved for storage with the patient's data record collection. 
For purposes of privacy or security, the medical computer network 
5 100 may deny access to some data records in the list of records to be 

retrieved. In such instances a substitute file, indicating that the requested file 
is confidential or has not been included, is created and stored, and its 
reference substituted for the reference to the confidential data record. 

In step 268, a retrieved data record may be further modified, such as 

10 by inserting additional hypertext links or data requests to the record per the 
hypertext cipher 138 (Fig. 3B). Also, the URL cipher 140 corresponding to 
the data type 136 (Fig. 3B) of the retrieved data record is used to format a 
URL by which the retrieved data record may be accessed. Further, the data 
translation and collection system 110 creates and opens an appropriate file 

15 folder and file to store the converted retrieved record as specified by the URL 
cipher 140 field. 

In step 276, the File Format Instruction Table 134 (Fig. 3B) for the 
instant database is checked to determine if additional data types 136 are 
available. If so, in step 272 the process of steps 220 through 276 is repeated 

20 for the next data type 136. If the search has been performed for each data 
type in the instant database, the search proceeds to the next database 
indicated in database register 131 (Fig. 3A), starting with its first data type 
136 and proceeding, in similar fashion, through each of its data types 136, 
until the search has been performed for every data type 136 of every 

25 database in database table 130 (Fig. 3A). The procedure progresses to step 
284 after completing this search through the registered databases. 

In step 284, the list of records to retrieve opened in step 212 is 
examined for the existence of records or program modules that have not yet 
been retrieved. If the list is empty, the data collection for the patient has been 

30 completed and the process advances to step 324 (Fig. 5E), discussed infra. 
If the list is not empty, in step 288 a request is sent for the first entry 
remaining in the list, which may be for a data record or a program module. If 
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it is a data record, after it is retrieved, it is checked in step 290 for encryption 
and decoded, if necessary, using proprietary software. 

In step 298, the record is parsed, discussed infra, to locate data 
references: hypertext links, multi-media requests, and key words or phrases. 
5 If none are found, the process advances to step 314, discussed infra. If there 
are data references a check is made to determine if the data begin referenced 
had been located previously (step 302). If it had not been previously located, 
the record is added to the List of Records to Retrieve (step 306). In step 310, 
all hypertext links and other data requests are reformatted through use of the 

10 URL Ciphers 140, maintained by the data translation and collection system 
1 10 for each data type 136. This way, the URL or other data request 
addresses are compatible with the addressing convention to be used on the 
storage medium to which the records will be written. When the retrieved data 
record is later displayed through a network browser, secondary files 

15 referenced by the retrieved data record are made easily and quickly 
accessible to the system user with the click of a mouse. 

In step 314, whether there were data references or not, Hypertext 
Cipher 138 is used to convert text to HTML format, graphics, audio, video, or 
other non-text information into a browser, plug-in, or Java compatible format. 

20 In step 316, the data translation and collection system 110 creates and 

opens an appropriate file folder and file to store the converted retrieved 
record, either as specified by the URL cipher 140 field (Fig. 3B) (if the 
retrieved record is part of the patient's file), or with a distinctive file name (if 
the retrieved record is not part of the patient's file, e.g., a physician's 

25 biographical background). In step 320, the retrieved record or program 

module, as it may be, is removed from the list of records to retrieve, and steps 
284 through 320 are repeated until the list is empty. 



The operation of the data translation and collection system 110 (Fig. 1) 
30 set forth in Figs. 5A-5E may be initiated in other ways. In one mode of 
operation, the databases 106 (Fig. 1) on the hospital's communication 



E. Workstation Data Collection and Translation 
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network 112 may send data for each patient to the data translation and 
collection system 110 periodically or after the patient is discharged. In 
another mode of operation, the workstations 102 on the hospital's 
communication network 112 may send reports, such as those produced by 
5 word processors, to the data translation and collection system for translation 
and storage. In yet another mode of operation, the data translation and 
collection system may have access to a drive, directory, or folder on one or 
more of the workstations 102 residing on the communication network, from 
which it may search and retrieve data records. 

10 System users such as physicians often produce reports, such as word 

processing files, on their own workstations 102 or 104 (Fig. 1) that are 
relevant to a patient's condition, status, or profile, and which merit inclusion in 
the data translation and collection system 110 of the present invention. This 
need may be accommodated by placing any report that is to be retrieved by 

15 the data translation and collection system 1 10 in a special folder 105 named 
"Collection." The data translation and collection system 110 may maintain a 
file containing a Workstation Data Table 150, as set forth in Fig. 4A, which 
includes the addresses 152 of all workstations 102 and physician office 
workstations 104 and file access commands 154 or passwords used to gain 

20 access to files stored in each workstation's "Collection" folder 105. The data 
translation and collection system 110 may also maintain a Workstation File 
Formatting Instruction Table 158, as set forth in Fig. 4B, which includes each 
report name and corresponding file name and data formatting instructions 162 
and Workstation URL cipher 166. 

25 On a periodic basis or as instructed, a program in the data translation 

and collection system 110 (Fig. 1) may determine if there are any files in the 
special "Collection" folder 105 in each workstation 102, 104. If any files exist, 
the file access commands 154 (Fig. 4A) may be sent to the workstation so 
that the files may be transferred to the data translation and collection system 

30 110. This may be done using the file transfer protocol, FTP, of the 
Internet/Intranet or by other data transfer methods. 

If the user of the workstation 102, 104 creates reports, that when 
stored use a file name formatted according to file name and data formatting 
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instructions 162 (Fig. 4B), the file may be recognized as being a specific file 
for a patient. For example, the file named "Cath987654321" may correspond 
to a catheterization report for the patient whose identification number is 
987654321 . Appending the date and time to the file name may be used to 
5 further identify the report. Alternatively, file name and formatting instructions 
162 may require that the date and time be located within the report itself. 
Similarly, the report name and/or the patient's identification information may 
be incorporated in the report or its file name. In either case, once the file and 
its file name are received and recognized, the file may be processed in the 
10 same manner that data records retrieved from databases are processed as 
set forth in Figs. 5A-5E, but using the Workstation Data Table 150 and its 
Workstation File Formatting Instruction Tables 158 in place of the Database 
Table 130 and its File Formatting Instruction Tables 134. 



1 5 any database 1 06 (Fig. 1 ), but that are capable of writing data to a floppy disk 
or transmitting information via an infrared or serial line connection to a 
workstation 102, 104 may also store patient reports in the data translation and 
collection system 110. To do so, the individual reports may be written to a 
floppy disk using any file name defined by the file name and data formatting 

20 instructions 162 (Fig. 4B). The reports may be copied manually or 

automatically from the floppy in workstation 102, 104 to the "Collection" folder 
105, which may be periodically checked to see if there is any data in it to be 
retrieved, or the reports may be automatically read by the workstation and 
sent to the data translation and collection system 110. The reports so sent 

25 may be incorporated with any others received for this patient and may be 

provided with a new destination file according to the Workstation URL Cipher 
166. 

In this manner reports from wordprocessors or from mobile medical 
devices may be collected for display and storage and may be assigned 
30 structured file names to assist in their retrieval whether on line or when placed 
on line as with a CD-ROM device 117 (Fig. 2). 



Instruments or medical devices whose reports are not stored as part of 
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F. Creation. Structuring, and Mass-Media Storage of Patient Data 

Commencing with step 324, Fig. 5F sets forth the process by which a 
patient's many data records may be stored on a mass storage device. In step 
324, a master file 400 (Fig. 6A) is created as data records are received or 
5 when all the data records have been retrieved. The master file name may be 
based on the patient's name or identification number. In some cases it may 
be desirable to create the same file twice, using the patients name for the file 
name once and the patient's identification number for the other. In step 328, 
secondary, tertiary, or other subdominant control files 418 (Fig. 8A) may also 

10 be created. A "master" file is roughly analogous to a root directory or a home 
page on a website, for through this single file all the patient's data records 
may be accessed through hypertext links. While a "master" file may contain 
text, graphics, video, or audio, it contains a list of links to other reports — for 
example, the discharge report link 408 (Fig. 6B) to discharge report 412 (Fig. 

1 5 7A) — or links to other "control" files — for example, the cardiology link 404 to 
cardiology control file 418 (Fig. 8A). "Control" files are roughly analogous to 
subdirectories. Although they incorporate text, graphics, or other multimedia 
features, they serve primarily to present an organized collection of links to 
related patient records. 

20 The URL Cipher 140 corresponding to the date type 136 of each data 

record retrieved, can be used to determine whether a hypertext link to retrieve 
the data record from the mass storage device is to be placed in a master, 
secondary, or tertiary control file. 



25 device along with the data records if they have not been previously been 

written to the mass storage device. A CD-ROM disk that has a patient's data 
written to it may be given to appropriate physicians for their own storage and 
use. To view the contents of the CD-ROM, a physician would need only to 
insert it into the CD-ROM drive 117 (Fig. 2) of a physician workstation 104 

30 (Fig. 1) and run a network browser program. By using the File command the 
physician could refer to the CD-ROM drive 117, which would list the name of 
the master file 400, which may be the same or similar to the patient's name. 



In step 332, the master and control files are written to a mass storage 
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Fig. 6A sets forth an example of the contents of the master file 400. 
Besides identifying the patient and the dates and source of the medical 
records, the master file has a series of hypertext links 402 either to distinct 
reports, such as hypertext link 408, or to secondary control files, such as 
5 hypertext link 404. Fig. 6B sets forth how master file 400 (Fig. 6A) might 

appear through a browser program when presented on display 118. Note that 
hypertext links 402 are displayed in a different font format, as is the 
convention with browser programs. The system user may select a hypertext 
link by moving a pointing device such as a mouse over the text and pressing 

10 an activation button. The browser will automatically retrieve the file specified 
in the hypertext link 402 from the CD-ROM and present it. 

If the system user selects the hypertext link 408 specifying discharge 
report in the master file 400, the system user will be presented with the 
patient's single discharge report 412 (Fig. 7A). Fig. 7A sets forth some of the 

15 HTML codes which may be used to format discharge report 412. Hypertext 
link 416 may be selected to retrieve the specified catheterization report from 
the CD-ROM. The hypertext link URL address has been modified as needed 
to make it compatible with the storage structure of the CD-ROM. Fig. 7B sets 
forth how discharge report 412 (Fig. 7A) might appear through a browser 

20 program when presented on display 118. 

Fig. 8A sets forth the contents of a secondary control file 418 that a 
browser program would present if the system user, while viewing master file 
400 (Fig. 6A), selected the hypertext link 404 specifying cardiology data. 
Secondary control file 418 presents the system user with various types of 

25 cardiology reports to choose from in the form of hypertext links 422. For 
those cardiology tests for which there is only one report available, the 
hypertext link specifies the URL address of that report. For those tests for 
which there are several reports available, the hypertext link 420 may specify 
the URL of a tertiary control file. Fig. 8B sets forth how secondary control file 

30 418 (Fig. 8A) might appear through a browser program when presented on 
display 118. 

Fig. 9A sets forth the contents of tertiary control file 424 that a browser 
program would present if the system user, while viewing secondary control file 



-33- 




418 (Fig. 8B), selected the hypertext link 420 specifying electrocardiograph 
reports. This file presents the system user with a list of all the 
electrocardiograph reports, during the dates selected, to choose from in the 
form of hypertext links 426. For each electrocardiograph report the hypertext 
5 link specifies the URL address of the report. Fig. 9B sets forth how tertiary 
control file 424 (Fig. 9A) and its list of electrocardiograph reports might 
appear through a browser program when presented on display 118. 



parsed to locate data references by searching it for text corresponding to a 
hypertext link or a multimedia data request. If one is found, the URL is 
located after the initial control sequence and will be saved (step 812) for use 
after the parsing is completed. If none are found, or when the record has 

1 5 been completely parsed, another pass can be made to search for data 
references in the form of key words or key phrases (step 820). 

A key word or phrase is a recognized text string that is to be converted 
into a hypertext link. As an example, the data reference indicated by the 
phrase, "Admission ECG," can be converted (steps 828, 830) into the 

20 following hypertext link: 

<a href="hww.st_mary.springfield/ecg/987654321/ 
03may 1 997/ecg/admission.html M >Admission ECG</a>. 

The expression "03may1997" is the date the data record being parsed was 
created. The patient ID (987654321), the date, and other descriptors are 

25 available from steps 200 and 226, or from steps 544 or 560. A wide variety of 
medical expressions can be recognized as key words or phrases, and 
appropriate hypertext links created from them. The URL of the hyperlink is 
saved for later use (step 832). When the entire record has been searched 
(step 836), the URLs of the located data references are returned to the 

30 section of the flow chart that requested the record to be parsed (step 840). 



G. Parsing to Locate Data References 



10 



Fig. 15A illustrates how a data record is parsed. A data record is 
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H. Building Addresses Using Gleaned Information 
and Data References in Batch 



It is contemplated that abbreviated database tables which includes at 
least some of the information included in database table 130, file format 
5 instruction tables 134 (including hypertext ciphers, URL ciphers and special 
instructions), tables 150 and 158 and data request catalogue 500 can be 
used to "build" addresses of records referenced in a specific record during 
batch processing of the specific record (i.e. after the entire first record has 
been entered). 

10 To this end, referring now to Fig. 21, a first abbreviated database table 

1800 preferably includes only data references (DRs) 1802 and associated 
URL's or address formats 1804. The DRs 1802, like the keywords described 
above, are searchable terms or phrases which are commonly used to refer to 
specific occurrences which may be associated with stored records. For 

15 example, "admission ecg" may be a DR 1802. Other DRs may include "post- 
op x-ray", "PET image", a date, a patient's identification number, etc. The 
address formats 1804, like the URL's described above, specify required 
information needed to form an address of a record associated with the 
corresponding DR and also specify the sequence of address fields which 

20 have to be filled with the required information to form the address. 

Referring to Fig. 22, the second abbreviated database table 1820 
includes global instructions 1822 and a list of data types 1824 and 
corresponding record rule sets (RRSs) 1826. The global instructions 1822 
include rules for identifying the data type 1824 of a record which is being 

25 searched (e.g. to identify key words or phrases for creating links to other 
records on the system databases 106, 2) in batch form. Different data types 
1824 are associated with different record information configurations. For 
example, one five field record may include a date in the second field while 
another may include the date in the fourth field. Yet a third record may 

30 include the date in the second field but may also include a total of seven 
fields. These three records would be characterized by three different data 
types 1824, each different data type 1824 having a different information 
configuration. 
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The global instructions 1822 may take any form which, given the data 
types 1824 used with the wordprocessor 14, can be used to identify a data 
type 1824. For example, wordprocessor 14 may always provide a single field 
specifically reserved for a character or symbol which identifies the record data 
5 type 1824. For instance, an ecg report may always be entered into a HIS 1 1 1 
( see Fig. 1) using a first data type template including specific fields for specific 
information (e.g. patient ID, date, time, physician, etc.). In this case, when an 
ecg data type template is opened to form an ecg record, wordprocessor 14 
automatically enters a "1" in the data type field. Similarly, when a PET scan 

10 report is entered into the HIS, assuming PET scan reports are of a second 
record type, wordprocessor automatically enters a "2" in the data type field. 

In the alternative, other global instructions 1822 may specify rules by 
which wordprocessor 14 can glean information entered by a user into record 
or template fields to determine the data type. For example, where a user 

15 enters a date into a fourth field instead of into a second field, wordprocessor 
14 can distinguish a unique data type 1824 or at least a sub-group of data 
types. Similarly, wordprocessor 14 may recognize specific terms entered into 
certain fields to identify data type 1824. For example, when a user enters 
"ecg" into a first field, wordprocessor 14 may recognize a specific data type 

20 based on global instructions 1822. While only two different examples of 

global instruction have been described herein, the examples are not meant to 
be exhaustive and other examples are contemplated. 



25 the system databases 106, 2. The RRSs 1826 each include a set of rules for 
gleaning information from a record which is being searched (e.g. to identify 
key words or phrases for creating links to other records on the system 
databases 106, 2). For example, where DT-1 1828 indicates a first record 
type having five fields including a first patient ID field, a second date field, a 

30 third report type field, a fourth physician name field and a fifth text field, the 
corresponding RRS-1 1830 includes rules which specify that to glean the 
patient ID, date, report type and physician name, wordprocessor 14 must 
access the first, second, third and fourth fields, respectively. 



Referring still to Fig. 22, the data types 1824 correspond to the 
different field configurations of the various record which are stored on the in 
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Referring now to Fig. 16, a batch method performed by wordprocessor 
14 ( see also Fig. 1) is illustrated. The method of Fig. 16 will be described in 
the context of an exemplary process. To this end, it will be assumed that a 
plurality of records have already been stored at database addresses 
5 according to the methods described above and in accordance with the 
specifications of the tables of Figs. 21 and 22. Thus, each of the stored 
records is associated with a DR 1802 and is stored at a database address 
which has a format indicated by an associated address format 1804 in the 
table of Fig. 21. For example, a record associated with DR-3 1808 is stored 

10 at an address having a format consistent with Format 3 1810. Records which 
have already been stored will be referred to generally as first records. 

In addition, referring also to Fig. 17, it will be assumed that the record 
illustrated therein (hereinafter a "second record") has been entered into the 
HIS and stored on one of the system databases 106, 2. The record in Fig. 17 

15 is a report created using wordprocessor 14. The record includes DRs 1608 
which reference a plurality of the first data records. Initially it is contemplated 
that DRs 1608 would not be highlighted but that, after wordprocessor 14 
forms links between DRs 1608 and records corresponding to the DRs 1608, 
the DRs 1608 would be highlighted via holding or a different color text. In Fig. 

20 17 the DRs 1608 include "admission ecg," "previous ecg," "previous 

discharge cath," and "admission CK enzyme" referencing various stored first 
records. 

For each of the DRs 1608 (i.e. keywords) in Fig. 17, wordprocessor 14 
is capable of recognizing these DRs and correlating the DRs with address 

25 formats 1804 via table 1800! In addition, wordprocessor 14 is also capable of 
determining the data type 1828 of the record shown in Fig. 17 and an 
associated RRS 1826 using the global instructions 1822 from table 1820. 

For the purposes of this explanation it will be assumed that the data 
type 1824 for the record illustrated in Fig. 17 includes five fields. In addition 

30 to a text field 1607, the four other fields include a patient ID field 1600, a date 
field 1602, a report type field 1604 and an author field 1606. It is also 
assumed that each of fields 1600, 1602, 1604, 1606 and 1607 already 
includes the information illustrated in Fig. 17. 
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In addition, the record of Fig. 17 also includes a data type field 1610. 
In the present example, it is assumed that, at an earlier time, when a 
physician accesses wordprocessor 14 to create a record, the physician 
indicates the data type to the wordprocessor in some manner. Data type may 
5 be indicated by selecting a data type from a list (e.g. ecg, PET report, post op 
X-ray, etc.) or it may be typed or it may be indicated in any other manner. 
When the physician indicates a data type 1824, word processor 14 places a 
character or a character string in data type field 1610 indicating the data type 
of the record being created. In addition, wordprocessor 14 thereafter can 

10 provide fields to be filled in which are consistent with the specified data type 
1824. In this case, it is assumed that "DT-1" indicates an admission report 
having fields 1600, 1602, 1604, 1606, 1607 and 1610. 

With the second record completed as illustrated in Fig. 17 and stored 
on one of the system databases 106, 2, a command is issued to 

15 wordprocessor 14 to search the second record to identify any references to 
first records which occur in the second record and, when a reference to a first 
record is located, to form a link between the reference and the referenced first 
record. To this end, wordprocessor 14 performs the process of Fig. 16. 
Wordprocessor 14 separately receives each phrase in field 1607 (where the 

20 phrases include groupings of N or less consecutive words where N is the 
maximum number of consecutive words which may be included in a DR 
1802), and compares each phrase to DRs 1802 in table 1800 to identify DRs 
1802. Where a phrase does not match a DR 1802, wordprocessor 14 jumps 
to the next entered phrase. 

25 Referring to Figs. 16 and 17, when the phrase "admission ecg" is 

received as a second record segment at step 1500, at step 1502 
wordprocessor 14 accesses table 1800 and compares the phrase "admission 
ecg" to the DRs 1802 until either a match is identified or until the phrase has 
been compared to all of the DRs 1802. In the alternative, table 1800 entries 

30 may be stored alphabetically and wordprocessor 14 may be equipped to 
recognize the first letter in a phrase. In this case, wordprocessor 14 may 
compare the phrase only to DRs 1802 which begin with the first letter of the 
phrase being compared to speed up the comparison process. At decision 



-38- 



block 1504, where the phrase does not match a DR 1802, control passes 
back to processes step 1500 where the next record phrase or segment is 
received for comparison. 

However, at block 1504, where the phrase matches a DR 1802, control 
5 passes to block 1 508. In the present example it will be assumed that DR-3 
1808 corresponds to the phrase "admission ecg M . Thus, the phrase 
"admission ecg" matches a DR-3 1808 and control passes to block 1508. At 
block 1508 wordprocessor 14 uses table 1800 to identify address format (i.e. 
URL cipher) 1810 which corresponding to DRs 1808. As indicated above, the 
10 address format specifies a format of an address associated with DR-3 1808 
and also specifies the required information needed to form the record 
address. 

Next, at process block 1510, wordprocessor 14 accesses the global 
instructions 1822 in table 1820 and uses the rules therein to determine the 

15 data type 1824 of the second record. In the present example, the global 

instructions 1822 instruct the wordprocessor to access data type field 1610 to 
identify the data type 1824. Accessing field 1610, wordprocessor 14 
determines that the second record data type is DT-1 . Accessing table 1824, 
wordprocessor 14 correlates data type DT-1 1828 with RRS-1 1830. As 

20 indicated above, RRS-1 1830 specifies rules for how to glean the required 
information from the record illustrated in Fig. 17. For example, address 
format 1810 may require, among other information, a patient ID number and a 
date used to locate reports for a particular patient related to the date. In the 
present example, RRS-1 1830 may specify that the information in field 1600 

25 corresponds to a patient ID and that the information in field 1602 corresponds 
to the current date. 

Now using RRS-1 1830, at process block 1512, wordprocessor 14 
gleans the required information as specified by address format 1810 from the 
second record in the manner specified by RRS-1 1830. To this end, in the 

30 present example, wordprocessor 14 gleans the patient ID number and the 
date from fields 1600 and 1602. 

Next, at block 1512, wordprocessor 14 forms an address for the record 
referenced by DR-3 1808. At block 1514 wordprocessor 14 automatically 
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highlights the DR 1608 "admission ecg" in text field 1607 thus providing the 
DR "admission ecg" as a selectable segment. In addition, wordprocessor 14 
links the DR "admission ecg" to the formed address such that, when the DR 
"admission ecg" is selected (e.g. via a mouse controlled cursor or the like), 
5 the wordprocessor 14 automatically accesses the record stored at the formed 
address and provides the record to a user for review. 

In addition to information facially included in the second record, 
wordprocessor 14 may also glean other information associated with the 
second record for building a record address. For example, wordprocessor 14 

10 may be associated with a specific facility and therefore may associate every 
record generated by the wordprocessor 14 with the specific facility (i.e. St. 
Mary's Springfield). In this case, when gleaning information, wordprocessor 
14 may also glean information specifying the specific facility which is required 
to form an address. This information may be gleaned from any of a variety of 

15 locations including admit system 108, hospital information system 1 1 1 or 
some other system linked to a hospital database 106, 2. 

This process of comparing record segments to DRs 1802 and forming 
links between DRs 1802 and records referenced by the DRs 1802 is 
continued on the second record text. In the present example links are formed 

20 between phrases (i.e. DRs 1802) "previous discharge cath" and "admission 
CK enzyme" and records referenced thereby. For example, the address 
linked to the phrase "admission ecg" is identified by number 1700 while the 
address linked to the phrase "previous discharge ecg" is identified by number 
1702. 

25 In addition, information in fields 1600 through 1606 may also be 

recognizable DRs 1802. In this case wordprocessor 14 also forms links 
between information in those fields and corresponding records by first 
determining if the information in a field is a DR 1802, identifying the address 
format 1804 corresponding to the DR 1802, identifying required information 

30 for forming an address, identifying a data type 1824 corresponding to the 
record being searched, identifying the RRS 1826 associated with the data 
type 1824, gleaning the required information as indicated by the RRS 1826, 
forming an address for the record referenced by the DR 1802 by combining 
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the required information, providing the DR 1802 as a selectable segment and 
linking the selectable segment to the record via the formed address. For 
example, the address linked to the patient ID number and associated patient 
demographics is identified by number 1704 and the address linked to the staff 
5 directory information for Dr. Markelson is identified by number 1706. 

Referring now to Fig 18 therein is illustrated an HTML document 
corresponding to the document of Fig. 17 including hypertext addresses 
formed according to the process of Fig. 16. It can be seen that each of the 
DRs 1608 of Fig. 17 now includes a linking address. 
10 Referring also to Fig. 19, the document of Fig. 18 is illustrated as the 

document would be viewed via wordprocessor 14 or a standard network 
browser (not illustrated). As illustrated, six selectable segments have been 
highlighted (i.e. underlined), a separate selectable segment for each 
recognized DR. 

15 It should be noted that while the above-referenced batch processing to 

build record addresses has been described in the context of the 
wordprocessor 14, some other data translation and collection system (e.g. 
1 10 in Fig. 1 ) may be provided to perform exactly the same functions in batch 
format. 

20 It should also be noted that while specific fields may be provided in a 

record template for entering specific types of information, in another 
embodiment, a single field may be able to receive more than one type of 
information from which a wordprocessor or other type of device could glean 
the separate types of information for building a record address. For example, 

25 in one embodiment, a patient's ID number, a date, a time and perhaps other 
information may be provided in a single field, the wordprocessor 14 able to 
parse information in the single field to identify specific types of information. In 
this case, it is contemplated that there would have to be rules to avoid 
duplication of specific types of information in the single field. For example, 

30 there would have to be a rule that no more than one patient ID could be 

provided in the field or that, if more than a single patient ID were provided in 
the field, one of the ID numbers would have to be selected for generating an 
address. 
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In yet another embodiment of the present invention, referring to Figs. 
21 , 22 and 23, portions of the data in tables 21 and 22 are combined to form 
even a more abbreviated database table 1900 which can be used to form 
database addresses for DRs which reference a first record in a second 
5 record. To this end, table 1900 includes a data reference (DR) list 1902, and 
both address formats 1904 and record rule sets (RRSs) 1906 which are 
correlated with the DRs 1902. In this embodiment the DR list 1902 and 
address formats 1904 have the same purposes and forms as the list in Fig. 
21. 

10 However, instead of being linked to a second record type, a separate 

RRS 1906 is linked to each of the unique DRs 1902. In this case, each RRS 
1906 includes a set of rules which, independent of a second record's data 
type, indicate how to glean required information for forming a record address 
form the second record information. For example, a particular medical facility 

15 may require a patient ID be identified as "ID: " followed by a 9 digit number. 

In this case, the RRSs 1906 would specify that the term "ID: " followed by a 

9 digit number is a patient identification which can be used to populate a 
patient ID field in an address format. Similarly, the RRSs 1906 in this 
example include other rules which can be used to glean information from a 

20 second record for forming an address. 

Referring to Fig. 16, the method illustrated therein would be essentially 
the same using the table of Fig. 23 instead of the tables of Figs. 21 and 22 
and therefore, the method using table 1900 will not be explained here in 
detail. The only difference in the method of Fig. 16 when using table 1900 is 

25 that, at process block 1510, the wordprocessor does not have to identify the 
data type and identifies the RRS by correlating the RRS with the DR in table 
1900. 

I. Real Time Operation Of Address Building Using Ciphers 

U.S. Patent Application Number 08/727,293 which was filed on 
30 October 9, 1996 and is entitled "Method and System for Automated Data 
Storage and Retrieval with Uniform Addressing Scheme" is incorporated 
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herein by reference. That application teaches a system whereby, as record 
information is entered into a record, a wordprocessor analyzes the 
information in real time to identify keywords, roots or data references (DRs) 
which are references to other records which are stored or which may be 
5 subsequently stored on one of the system databases 106, 2. It is 

contemplated that the abbreviated database tables illustrated in Figs. 21 and 
22 can be used to "build" addresses of records referenced in a specific record 
as the record is entered into a wordprocessor database 2. Thus, the process 
of forming record addresses described above in the context of batch 

10 processing (i.e. processing after the records have already been entered and 
stored) can be practiced in real time. 

To this end, referring again to Fig. 16, the wordprocessor method 
illustrated therein can also be performed in real time. To describe real time 
operation of the wordprocessor 14 to generate links between records, once 

15 again, it will be assumed that a plurality of records have already been stored 
at database addresses according to the methods described above and in 
accordance with the specifications of the tables of Figs. 21 and 22. Thus, 
each of the stored records is associated with a DR 1802 and a corresponding 
data type 1828 and address format 140 1804. Records which have already 

20 been stored will be referred to generally as first records. In addition, referring 
also to Fig. 17, it will be assumed that the second record illustrated therein is 
being entered into the database 2 in real time. 

For each of the DRs 1802 (i.e. keywords), wordprocessor 14 is capable 
of recognizing these DRs 1802 in the document illustrated in Fig. 17 and 

25 correlating the DRs 1802 with address formats 1804 via table 1800. In 

addition, wordprocessor 14 is also capable of determining the data type 1828 
of the record shown in Fig. 17 as that record is being input in real time and an 
associated RRS 1826 using the global instructions 1822 from table 1820. 



30 type field 1610. In the present example, it is assumed that, when a physician 
initially accesses wordprocessor 14 to create the record of Fig. 17, the 
physician indicates the data type to the wordprocessor in some manner. For 
example, data type may be indicated by selecting a data type from a list (e.g. 



As in the batch example above, the record of Fig. 17 includes a data 
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ecg, PET report, post op X-ray, etc.). When the physician indicates a data 
type 1824, word processor 14 places a character or a character string in data 
type field 1610 indicating the data type of the record being created. In 
addition, wordprocessor 14 thereafter can provide fields to be filled which are 
5 consistent with the specified data type 1824. Once again, it is assumed that 
"DT-1" indicates an admission report having fields 1600, 1602, 1604, 1606, 
1607 and 1610. 

After fields 1600 through 1606 are filled, the physician is prompted to 
enter report text into field 1607. During text entry, wordprocessor 14 performs 

10 the process of Fig. 16. To this end, processor 14 receives each phrase 
entered into field 1607 (where the phrases include groupings of N or less 
consecutive words where N is the maximum number of consecutive words 
which may be included in a DR 1802), and compares each phrase to DRs 
1802 in table 1800 to identify DRs 1802. Where a phrase does not match a 

15 DR 1802, wordprocessor 14 jumps to the next entered phrase. 

Referring to Figs. 16 and 17, when the phrase "admission ecg" is 
received as a second record segment at step 1500, at step 1502 
wordprocessor 14 accesses table 1800 and compares the phrase "admission 
ecg" to the DRs 1802 until either a match is identified or until the phrase has 

20 been compared to all of the DRs 1802. At decision block 1504, where the 
phrase does not match a DR 1802, control passes back to processes step 
1500 where the next record phrase or segment is received for comparison. 



25 DR-3 1808 corresponds to the phrase "admission ecg". Thus, the phrase 
"admission ecg" matches a DR-3 1808 and control passes to block 1508. At 
block 1508 wordprocessor 14 uses table 1800 to identify address format (i.e. 
URL cipher) 1810 which corresponding to DRs 1808. As indicated above, the 
address format specifies a format of an address associated with DR-3 1808 

30 and also specifies the required information needed to form the record 
address. 

Next, at process block 1510, wordprocessor 14 accesses the global 
instructions 1822 in table 1820 and uses the rules therein to determine the 



However, at block 1504, where the phrase matches a DR 1802, control 
passes to block 1508. In the present example it will again be assumed that 
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Next, at process block 1510, word processor 14 accesses the global 
instructions 1822 in table 1820 and uses the rules therein to determine the 
data type 1824 of the second record. In the present example, the global 
instructions 1822 instruct the word processor to access data type field 1610 to 
5 identify the data type 1824. Accessing field 1610, wordprocessor 14 

determines that the second record data type is DT-1 . Accessing table 1824, 
wordprocessor 14 correlates data type DT-1 1828 with RRS-1 1830. As 
indicated above, RRS-1 1830 specifies rules for how to glean the required 
information from the record illustrated in Fig. 17. For example, address 
10 format 1810 may require, among other information, a patient ID number and a 
date used to locate reports for a particular patient related to the date. In the 
present example, RRS-1 1830 may specify that the information in field 1600 
corresponds to a patient ID and that the information in field 1602 corresponds 
to the current date. 

15 Now using RRS-1 1830, at process block 1512, wordprocessor 14 

gleans the required information as specified by address format 1810 from the 
second record in the manner specified by RRS-1 1830. To this end, in the 
present example, wordprocessor 14 gleans the patient ID number and the 
date from fields 1600 and 1602. 

20 Next, at block 1512, wordprocessor 14 forms an address for the record 

referenced by DR-3 1808. At block 1514 wordprocessor 14 automatically 
highlights the DR 1608 "admission ecg" in text field 1607 thus providing the 
DR "admission ecg" as a selectable segment. In addition, wordprocessor 14 
links the DR "admission ecg" to the formed address such that, when the DR 

25 "admission ecg" is selected (e.g. via a mouse controlled cursor or the like), 
the wordprocessor 14 automatically accesses the record stored at the formed 
address and provides the record to a user for review. 

This process of comparing record segments to DRs 1802 and forming 
links between DRs 1802 and records referenced by the DRs 1802 is 

30 continued as text is entered into the record text field 1607. In the present 
example links are formed between phrases (i.e. DRs 1802) "previous 
discharge cath" and "admission CK enzyme" and records referenced thereby. 
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In addition, as in the batch example above, information in fields 1600 
through 1606 may also be recognizable DRs 1802. Here, the only difference 
in wordprocessor 14 operation is that the DRs in fields 1600 - 1606 are 
recognized as the fields are filled and, if all of the required information is not 
yet entered for building an address, the wordprocessor 14 waits to build the 
address until all of the required information has been provided. For example, 
referring still to Figs. 17 and 21, where the patient ID field 1600 is recognized 
as a DR 1802 and the date in field 1602 is required to form an address to a 
record corresponding to the patient and the date, if the date has not yet been 
entered, the wordprocessor 14 must wait for the date to be entered prior to 
forming the address. In the alternative, the wordprocessor 14 may be 
programmed to wait until all fields 1600 - 1606 are filled prior to building any 
addresses for DRs (i.e. processing of information in the preliminary, non-text 
fields may be done in batch). 

It should be understood that while the real time addressing method 
described above is described in the context of the tables of Figs. 21 and 22, 
the table of Fig. 23 may be used instead, the only differences being that in 
step 1510 wordprocessor 14 does not identify the second record data type 
and that the wordprocessor 14 determines the RRS by correlating an RRS 
1906 in table 1900 with an identified DR 1902. 

While a particular embodiment of the invention has been illustrated and 
described, it will be obvious to those skilled in the art that various changes 
and modifications may be made without sacrificing the advantages provided 
by the principle of construction disclosed herein. For example, while the 
present invention has been described above in the context of an interface 
wherein a physician enters record information via a keyboard, clearly the 
invention is not to be so limited. For example, data may be dictated into a 
system, the inventive wordprocessor including voice recognition software and 
identifying DRS as they are dictated and forming links between the DRS and 
records referenced thereby. 

In the alternative, referring to Fig. 20, the system may be used with a 
data specifying device such as a hand held information gathering device 
(HHD) 1200 which downloads record information via a receiver (e.g. rf) 1202 
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which is entitled "Data Collection Device and System", which is commonly 
owned with the present application and which is incorporated herein by 
reference. In this type of system, the HHD may in fact specify a DR which 
can be used by processor to identify a DB address in any of several different 
5 ways. For example, processor 14 may simply correlate the DR with a DB 
address. In the alternative, processor 14 may build an address using the DR 
and an associated address format. In addition to specifying the DR, it is also 
contemplated that the HHD specifies other information for forming the DB 
address (e.g. background or general data set information such as patient ID, 
10 time, date, etc.). Also, it should be recognized that any data specifying device 
may be used such as a database which indicates a DR or the like. To this 
end, see the DB 106 linked to processor 14 via a network router 1206 or other 
network device (i.e. a receiver) in Fig. 20. 



15 also be used in the case of a proxy server which routes address commands 
and requests among network devices. For example, the invention may build 
record addresses which do not actually match record addresses on a 
database but which, when provided to a proxy server, enable the proxy server 
to identify the actual record addresses and form a link. 

20 To apprise the public of the scope of this invention, we make the 

following claims. 



Furthermore, it should be recognized that the present invention may 
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